Thanks for working on this @pbakaus! We'll begin testing and discussion of the implementation shortly.

I personally favor trying to find the minimal set of 'looks good enough, but doesn't require boilerplate' option, however I can also see value in all of the options being documented.

I'd prefer to keep it minimal too. H5BP has good docs for all this we could link to.

Pushed another commit with fixes. Reverted to 192px as baseline for the icon size, as Android is more important to support than Opera Coast (and Coast will eat the picture anyway, then scale up).

@sindresorhus Open for reviewing this, but if we do end up reducing scope or trimming implementation, there's always the docs directory which is prime for extended work like this.

Thanks for the PR! Before this can be merged, please sign the CLA at https://developers.google.com/open-source/cla/individual

Done!

On Mon, Sep 22, 2014 at 4:29 PM, Addy Osmani [email protected]
wrote:

Thanks for the PR! Before this can be merged, please sign the CLA at
https://developers.google.com/open-source/cla/individual

—
Reply to this email directly or view it on GitHub
#442 (comment)
.

I covered some of this stuff back in #60. I think that while thorough and correct, having all this in the initial markup will severely inhibit adoption. H5BP was avoided by many developers because of the sentiment "better to use something when you need it, rather than start with the entire kitchen sink". Which.. seems reasonable.

Favicons seemed solved these days by the combination of @mathiasbynens' eternally updated blog post and the comprehensive realfavicongenerator.net. And yet they change, too. iPhone 6+ added a brand new asset requirement.

I wonder if this is better suited to a build step rather than dirtying up the initial markup.

iPhone 6+ added a brand new asset requirement.

Note: Some things have changed since the iOS 8 release, however, the iPhone 6 Plus still uses the 120×120px touch icon like the other previous models of the iPhone do.

@paulirish @alrra Thanks for chiming in with your thoughts :)

I share your concern that including every possible combination will scare off beginners. I've also been hesitant to add icon generation to the build process for a few reasons (please do let me know if this is unreasonable):

• Real-world sites are likely to want to tweak and customize their icons per device manually, through an image editor to get the look right.
• Adding a build step to solve this problem would move the introduction of boilerplate from our HTML into our Gulpfile. This may end up making it feel like the 'kitchen sink'

That said, for funsies, here's what a build step for icon generator would look like using the Favicons module by @haydenbleasel:

favicons({
    // I/O
    source: 'images/logo.png',
    dest: 'dist/images/icons',

    // Icon Types
    android: true,
    apple: true,
    coast: true,
    favicons: true,
    firefox: true,
    windows: true,

    // Miscellaneous
    html: null,
    background: '#1d1d1d',
    tileBlackWhite: true,
    manifest: null,
    trueColor: false,
    logging: false,
    callback: null
});

The HTML option basically specifies the file (index.html etc.) to write the icon data to. It's unclear to me (without further testing) how well existing modules tackle generating icons + splashscreens, but this could be a start if we wanted to go down that route.

Any further thoughts?

Sup @addyosmani and crew. If you need a demo of Favicons, it'd look something like this. Creating a new branch for the Gulp plugin is on my to-do list. Also, let me know if you think of adding things like extra icons or splash screens (as mentioned), always happy to look into expanding the module. Good work with Web Starter Kit btw, loving it.

Thanks for sharing the demo @haydenbleasel. If the consensus is that a build process is the way to go here, we might have a few suggestions for additional icons/sizes that could be generated (the list from @pbakaus in this PR might be a good indication). Really cool to see your openness in expanding the module :)

+1 for build step. I think there's a lot of value to have all of them in place automatically when you need them, and not before.

Also it might be good to mention that Favicons isn't particularly light, it outputs a LOT of files (if that changes anything). See the Travis log for deets.

I agree with @addyosmani: taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon. For best results each icon is pixel-perfected individually, though. Then again I’m not sure how many designers actually do this.

Taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon.

That was my concern. That we may be making an assumption that automation is the right call here. That said, unsure without doing a survey how best to gauge if designers really do create these per project. Might warrant further research either way.

The best way is definitely to design each icon individually, but for most basic applications it's just a chore to get things right. However this does raise an interesting idea about defining multiple source images that range in complexity (for smaller and larger icon sizes)...—
Sent from Mailbox

On Tue, Sep 23, 2014 at 7:17 PM, Addy Osmani [email protected]
wrote:

Taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon.

That was my concern. That we may be making an assumption that automation is the right call here. That said, unsure without doing a survey how best to gauge if designers really do create these per project. Might warrant further research either way.

Reply to this email directly or view it on GitHub:
#442 (comment)

​Could the build task default to auto-resize but also take options for
manual selection of differently sized source images?

@paulirish Yeah I reckon I'll modify the source property to accept a string or array so we can get some better favicons happening.

+1 build step if:

1.) It can add in the markup
2.) It can be used to customise each specific favicons

An alternative is to move to static templating which would be easier on the eye and feel more manageable.

Yeah I reckon I'll modify the source property to accept a string or array so we can get some better favicons happening.

@haydenbleasel any timeline on when that might be available? :)

@gauntface could you expand on how static templating might fit in here?

What I'm thinking is, you might have one for ios 5+, one for Chrome add to home screen, one for Opera Coast and you just pull in a single template for each - it will look a little cleaner and make maintenance a little easier.

Chatting with @addyosmani - @haydenbleasel I think I'd almost prefer to have a separate icon for each category of device - i.e. an icon for iOS, one for Chrome for Android, one for Windows Phone.

What would people say to this approach?

I won't comment on the per category of device icons, but will say I'm more open to us opting for an automated solution to generating favicons having spoken to a few developers about it. What would be useful for us to consider here is:

• Minimal set of changes we would need from tooling (the kind Mr @haydenbleasel in this case)
• How we document customizing the icons if tooling is the default. It seems like we could use a guide for those that want to create per device icons with or without the tools in place.

Yeah there's kind of two methods i can implement:

1. Minimal solution, define a set of images that determine icons produced based on size e.g.

source: {
   small: 'small.png',
   medium: 'medium.png',
   large: 'large.png'
}

2. Descriptive solution, define an image for each favicon (can overlap) like @gauntface was talking about e.g.

source: {
   opengraph: 'large.png'
   apple: 'medium.png',
   android: 'medium.png',
   favicon: 'small.png'
   ...
}

Maybe a bit of discussion on this before I start working on something.

Having flexibility to specify a per target source as well as the option in 1 would be fantastic - would this basically allow us to support 3 possible configurations?

• User can specify just one hi-res image
• User can specify a small, medium and large set of images
• User can specify per target OS images

For 2) we'll want to make sure the high-level targets are at minimum supported (Android, Windows Phone, iOS) but it looks like you know what needs to be done there :)

@gauntface any other asks from your end? I would absolutely love to be able to land support for build-time generation in 0.6.0

Okay @addyosmani, new version of Favicons is out. Besides a few async fixes there's also support for an OpenGraph image which I must have forgotten initially. The important stuff though:

You can now define multiple source images like so:

source: {
    small: 'logo-small.png',    // Should be 64x64px or smaller
    medium: 'logo-medium.png',  // Should be between 65x65px to 310x310px
    large: 'logo-large.png'     // Should be 311x311px or larger
}

I've taken the route of multiple source image sizes suggested by @mathiasbynens and @paulirish rather than the per-platform route proposed by @gauntface as each platform has sizes that can range from around 16px to 310px. Therefore I've had each platform select a source image depending on the size I'm about to convert them to.

Also gave you blokes a mention on the readme for good measure. Hope this helps and let me know if there's anything else I can help with!

Fantastic work @haydenbleasel 🌟

@gauntface @paulirish I think the next step forward here is to decide whether we want users to define 2-3 multi-res images for their projects vs a single high-res image we use to seed the icons being generated.

In either case, we can provide them with some WSK flavoured defaults and comment up the Gulpfile with more detail about customization. Any preferences here?

I would want to have an ios, a chrome and a IE + Opera Coast icon - high res for each

Could the default be ask users for a single image, but also recommend providing three unique ones instead? Could then take the time to describe what each asset is used for and recommendations on visual treatment.

I feel asking for three separate assets here by default is a lot to ask.

I feel asking for three separate assets here by default is a lot to ask.

👍 For a simple default.

+1 for what Paul suggested. Asking for three unique ones would be quite annoying, but there must be an opportunity to input them all three.

Goooood to see we're on similar pages. Fwiw, my vote is for a single asset by default too. We can document and include comments guiding them to define three but assume most people will just go for the simplest setup possible.

@gauntface sgty?

friendly ping @gauntface :)

@addyosmani Quick update you might find interesting, I've been talking with the creator of the aforementioned realfavicongenerator.net and we might be doing some work together that will make Favicons and RFG more awesome (using his comprehensive API).

👍 That is great to hear :) Looking forward to learning more when you have the details hammered out!

+1 from me to get this in. I think some of the files could be renamed and the splash screens have slightly rotated WF logo's, but this can be fixed up after accepting and are minor issues given that we hope developers will change these anyway.

ping @phbernard - read this stuff too :)

fwiw,

I've been talking with the creator of the aforementioned realfavicongenerator.net and we might be doing some work together that will make Favicons and RFG more awesome (using his comprehensive API).

All, there is a status update ("in progress!") on that over here: itgalaxy/favicons#14

Oh, I feel like I missed the party! :) If that can help, here is the opinionated approach of realfavicongenerator.

The tool has two constraints in mind:

• Many people have little knowledge of Photoshop, Gimp or whatever and/or have not enough talent to do serious graphic design. That's me. So everything they have is a high resolution logo from their customer, marketing department...
• Many people don't have time to deal with this tiny little thing named favicon. It should be a 5 minutes task just before lunch time.

Web devs/designers with talent and time are welcome and RFG let them do as they want (yet some improvements are expected in this area) but this is not the primary use case.

This is compliant with the idea of @addyosmani and @paulirish to submit a single, high res picture. And more pictures if available.

Next, RFG has two tasks:

• The obvious task: generate the pictures and HTML code that work everywhere.
• The tricky task: make the icon look good everywhere. Different platforms need different designs. Let's take the favicon of GitHub, a black silhouette on a transparent background. If we take a high res version of this picture and make it a apple-touch-icon.png, adding it to the home screen will produce a black square. Because iOS fill transparent regions with black. To be a decent iOS icon, this picture needs an opaque background and margins (else, the silhouette touches the borders).

I think this last point is really important. It is easy to miss it and focus only on the technical aspects.

As @paulirish mentioned a few hours ago, @haydenbleasel and I have started to work together on RFG integration in his neat Gulp plugin.

Closing this off to move the discussion to this issue: #599